home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / T0416 / text0004.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  3.2 KB  |  63 lines
  1.  
  2. >Yes, it's very easy to add, but I'm not thinking about point lightsourcing -
  3. >just a single solar source which can even be precalculated on the level-loading
  4. >pass.
  5.  
  6. >     Well, perhaps I misunderstood you, but I think it would be possible to
  7. > use a 'Lightsource' Thing for BMW files, and to precalculate those Lightsources
  8. > during the loading... Am I wrong ? If it's possible, no doubt that it would be
  9. > more beautiful than those bloody flashing sectors that we can see in Doom
  10. > levels... :)
  11.  
  12. Yes - this is slightly more complex than what I proposed above, but it's essentially
  13. the same as far as the engine is concerned. It's also very easy to do. The problem
  14. lies in user level-design, as it would be very hard to predict what effect a
  15. particular light is going to have on the scene. Remember that we can only light up
  16. entire wall / floor segments at a time, since this is not a Quake engine! :)
  17.  
  18. In other words, by increasing the complexity of the lighting without increasing
  19. the detail level, you might end up with unusual results - simply down to the lack
  20. of surfaces. Simple rooms would just look silly, where complex ones would look great.
  21.  
  22. By restricting lightsourcing to a single solar source, the results become more predictable
  23. and coherent - which tends to be more useful to a level designer.
  24.  
  25. However, the ultimate test would be to try it out... 
  26.  
  27. >    About the 'bloody flashing sectors', I saw that oftenly, when the
  28. >flashing sector is dark, it is darker than the non flashing sectors... It would
  29. >be cool to fix this, if you have time between your professional developments
  30. >(which will sure be _GREAT_ !).
  31.  
  32. I know this looks silly just now, but I can't really fix it until I can find a list
  33. detailing what the different lighting-codes are supposed to do. The doom-spec docs
  34. are a bit 'thin' on this subject, and I have just done it simply for the moment.
  35.  
  36. I will fix it later on when I get the relevant info - and we can then start adding
  37. custom lighting codes (coloured lights etc.) for later.
  38.  
  39. >    About Apex 3 : will it keep the Apex 2 animation tools ?
  40.  
  41. Apex is being split in half to allow us to make it better. Keeping the Animator mixed
  42. up with the image processing & filtering stuff is causing all sorts of problems.
  43.  
  44. What we are trying to do is to START with a new (non-Gem) window-based painting /
  45. filtering / processing program with all the Apex stuff (minus animation) built-in.
  46.  
  47. This is mainly to satisfy users who complain that Apex v2's painting / processing abilities
  48. are currently too limited. It does sound like Apex is being cut back, but it's quite
  49. the opposite - it's already way ahead of Apex v2.
  50.  
  51. Afterwards, we will either develop a new Animator, with a better balance of animation
  52. features, or we will build the animation into the painting system. Whichever way we do
  53. it, there will be a much better animator before too long.  This is likely to mean a
  54. window-based Animator, with a flic in every window, and hundreds of 'pages' in each
  55. Flic. You can even have a different zoom level in each window, and play multiple flics
  56. simultaneously. This has a much greater scope than Apex v2.
  57.  
  58. I hope that answers your question, but I also hope you can see that developing Apex v2
  59. any further would not allow the flexibility of this new route.
  60.  
  61. Doug.
  62.  
  63.